Today, we released the 11th volume of our annual State of Software Security (SOSS) report. This report, based on our scan results, always offers an abundance of insights and information about software vulnerabilities – what they are, what’s causing them, and how to address them most effectively. This year is no different.
With last year’s SOSS Volume 10, we spent some time looking at how much things had changed in the decade spanning Volume 1 to Volume 10. With Volume 11, we are going to look forward and consider the direction software development is headed. We are not trying to decide if we are doing better or worse than before, but looking at what kind of impact the decisions developers make have on software security.
Some key takeaways:
Most applications are vulnerable. Our analysis this year found that among 130,000 apps, 76 percent had at least one security flaw. But in the good news department, most apps do not have severe vulnerabilities. Only 24 percent had high-severity security flaws. Back to the bad news: fix rate is still an issue – half of security findings are still open 6 months after discovery.
Open source code is expanding the attack surface. Applications increasingly include open source libraries; in fact, many now include more open source than first-party code. This year, we found that 97 percent of a typical Java application is made up of third-party code. And when we looked at our analysis of open source code through Software Composition Analysis vs. first-party code through Static Analysis, we found that almost one-third of all applications have more findings in third-party libraries than in the native code base.
There are ways to “nurture” software security, even if the “nature” of your software is less than ideal. This year, we thought about what leads to the state of software security – is it “nature” or “nurture”? Is it the attributes of the app that the developer inherits – its security debt, its size –or is it the actions of the developers – how frequently they are scanning for security, or how security is integrated into their processes? And if it’s “nature,” is there anything developers or security pros can do to improve security outcomes? This year’s research unearthed some surprising – and promising – data surrounding ways to “nurture” the security of your applications, even if the “nature” is less than ideal. For example, those who scan via API (and therefore are integrating and automating security testing) shorten the time to address half their flaws by 17.5 days.
See below for the data highlights, and check out the full report for all the data details, plus our advice on how to use the story told by the numbers to improve your own application security program.